Definiowanie zachowania obiektów

Metody instancyjne i klasowe, klasy abstrakcyjne, interfejsy

apohllo@agh.edu.pl

http://apohllo.pl/dydaktyka/programowanie-obiektowe

konsultacje: wtorek 15:30 - 18:00, pokój 4.61

Definiowanie (publicznego) zachowania

enum SpeedUnit {
    KMH, MS
}

class Speed {
    public double value;
    public SpeedUnit unit;
}

class SpaceShip {
    private Speed speed;

    public SpaceShip(){
        this.speed = new Speed();
        this.speed.unit = SpeedUnit.MS;
    }

    public void accelerate(Speed delta){
        if(delta.unit == this.speed.unit && delta.value > 0) {
            this.speed.value += delta.value;
        }
    }
}

class LandVehicle {
    private Speed speed;

    public LandVehicle(){
        this.speed = new Speed();
        this.speed.unit = SpeedUnit.KMH;
    }

    public void accelerate(Speed delta){
        if(delta.unit == this.speed.unit) {
            this.speed.value += delta.value;
        }
    }
}

Brak definicji operacji w klasie Speed powoduje, że ten sam lub niemal identyczny kod definiowany jest w wielu miejscach, co w konsekwencji powoduje przyrost pracy związany z modyfikacjami oraz usuwaniem błędów - zmiany i poprawki trzeba wprowadzać w wielu miejscach w kodzie. Ponadto prowadzi do niespójności w sposobie definiowania zachowania obiektów.

class Speed {
    private double value;
    private SpeedUnit unit;

    public Speed(double value, SpeedUnit unit){
        this.value = value;
        this.unit = unit;
    }
    
    public Speed add(Speed that){
        if(this.unit == that.unit){
            return new Speed(this.value + that.value, this.unit);
        } else {
            return this; // lepiej rzucić wyjątek lub dokonać konwersji
        }
    }
    
    public boolean isAboveZero(){
        return value > 0;
    }
}

Metody pozwalają na definiowanie zachowania obiektów w określonej dziedzinie problemu. Różnica względm języków proceduralnych polega na tym, że metody są ściśle związane z danymi (stanem) obiektów i pozwalają na wyrażanie kodu programu w języku dziedziny problemu.

class SpaceShip {
    private Speed speed;

    public SpaceShip(){
        this.speed = new Speed(0, SpeedUnit.MS);
    }

    public void accelerate(Speed delta){
        if(delta.isAboveZero()) {
            this.speed = this.speed.add(delta);
        }
    }
}

class LandVehicle {
    private Speed speed;

    public LandVehicle(){
        this.speed = new Speed(0, SpeedUnit.KMH);
    }

    public void accelerate(Speed delta){
        this.speed = this.speed.add(delta);
    }
}

Wprowadzenie metod add oraz isAboveZero spowodowało, że powtórzenia kodu zostały usunięte. Nie ograniczyło to jednak możliwości elastycznego wykorzystania klasy - SpaceShip nadal pozwala tylko na zwiększanie prędkości.

Publiczne zachowanie obiektu definiowane jest za pomocą metod z modyfiaktorem public. Oznacza to, ze mogą być one wywoływane w dowolnym kontekście.

Modyfikacja zachowania w klasie dziedziczącej

Wieloryb jest ssakiem, ale różni się od typowego ssaka tym że mieszka w wodzie a jego kończyny to płetwy. Można powiedzieć, że "modyfikuje" typowe cechy jakie kojarzymy ze steoreotypem ssaka.

Speed speed0 = new Speed(10, SpeedUnit.KMH);
speed0.toString();

REPL.$JShell$17BCS$Speed@7cdb2ef8

class Speed {
    private double value;
    private SpeedUnit unit;
    
    public Speed(double value, SpeedUnit unit){
        this.value = value;
        this.unit = unit;
    }
    
    @Override // <- nie jest wymagane, żeby zadziałało
    public String toString(){
        return "" + value + " " + unit;
    }
}

Każda klasa dziedziczy pośrednio lub bezpośrednio z klasy Object. W tej klasie zdefiniowana jest m.in. metoda toString, która odpowiedzialna jest za zamianę obiektu na łańcuch znaków.

(override = nadpisanie)

Speed speed1 = new Speed(10, SpeedUnit.KMH); // <---- Speed
speed1.toString();

10.0 KMH

Object speed2 = new Speed(10, SpeedUnit.KMH); // <---- Object!
speed2.toString();

10.0 KMH

Mimo tego, że deklarujemy speed2 jako Object to wykorzystywana jest metoda toString() zdefiniowana w klasie Speed.

Innymi słowy zasadniczo metody w Javie są wirtualne.

Rozszerzenie zachowania klasy nadrzędnej

Aksolotla jest niezmiernie ciekawym organizmem. Zasadniczo przykład ma ilustrować możliwość przebywania w wodzie oraz chodzenia po lądzie, choć larwarne stadium tego płaza nie wychodzi na ląd. Po prostu ilustracja jest ładna ;-)

class Speed {
    private double value;
    private SpeedUnit unit;

    public Speed(double value, SpeedUnit unit){
        this.value = value;
        this.unit = unit;
    }

    @Override
    public String toString(){
        return super.toString() + " " + value + " " + unit;
    }
}

Speed speed1 = new Speed(10, SpeedUnit.KMH);
speed1.toString();

REPL.$JShell$17FT$Speed@3e37b0bf 10.0 KMH

Pola vs. metody

enum SpeedUnit {
    MS, KMH, MA
}

class Speed {
    public double value = 0;
    public SpeedUnit unit = SpeedUnit.MS;
}

class SuperSonicSpeed extends Speed {
    public double value = 10;
    public SpeedUnit unit = SpeedUnit.MA;
}

Speed speed1 = new Speed();
System.out.println(speed1.unit);
System.out.println(speed1.value);

MS
0.0

Speed speed2 = new SuperSonicSpeed(); // <--- zmienna typu Speed
System.out.println(speed2.unit);
System.out.println(speed2.value);

MS
0.0

SuperSonicSpeed speed3 = new SuperSonicSpeed(); // <--- zmienna typu SuperSonicSpeed
System.out.println(speed3.unit);
System.out.println(speed3.value);

MA
10.0

Jest to podstawowa różnica między polami w klasie, a metodami w Javie. Klasa dziedzicząca może nadpisać metodę i ta zmiana jest "widoczna" w klasie nadrzędnej. Klasa dziedzicząca może dodać ten sam atrybut, ale to, który atrybut zostanie użyty zależy od zadeklarowanego typu zmiennej! Krótko podsumowując - metody są wirtualne, a pola nie są wirtualne. Użycie dwóch tych samych nazw zmiennych to shadowin (przesłanianie) a użycie tych samych nazw metod to overriding (nadpisywanie).

Modyfikator private

class Speed {
    protected static final double MS_TO_KMH_RATIO = 3.6;
    
    protected double value;
    protected SpeedUnit unit;
    
    public Speed(double value, SpeedUnit unit){
        this.value = value;
        this.unit = unit;
    }
    
    public Speed add(Speed that){
        return new Speed(this.value + that.convert(this.unit), this.unit);
    }
    
    public Speed subtract(Speed that){
        return new Speed(this.value - that.convert(this.unit), this.unit);
    }
    
    public String toString() {
        return "" + this.value + " " + this.unit;
    }

    private double convert(SpeedUnit target){
        if(this.unit == SpeedUnit.KMH && target == SpeedUnit.MS){
            return this.value / MS_TO_KMH_RATIO;
        } else if(this.unit == SpeedUnit.MS && target == SpeedUnit.KMH){
            return this.value * MS_TO_KMH_RATIO;
        } else {
            // pozostałe przypadki
            return this.value;
        }
    }   
}

Speed speed1 = new Speed(10, SpeedUnit.MS);
Speed speed2 = new Speed(36, SpeedUnit.KMH);
speed2.add(speed1);

72.0 KMH

speed1.convert(SpeedUnit.MS);

|   speed1.convert(SpeedUnit.MS);
convert(SpeedUnit) has private access in Speed

Zasadniczo metody prywatne są "szczegółami implementacji", więc nie można ich wywoływać "z zewnątrz"

class SuperSonicSpeed extends Speed {
    public SuperSonicSpeed(double value){
        super(value, SpeedUnit.MA);
    }
    
    public Speed subtract(SuperSonicSpeed that){
        return new Speed(this.value - that.convert(this.unit), this.unit);
    }

    public double convert(SpeedUnit target){
        return 0;
    }
}

Wywołanie super powoduje wywołanie konstruktora z klasy nadrzędnej.

SuperSonicSpeed speed1 = new SuperSonicSpeed(10);
SuperSonicSpeed speed2 = new SuperSonicSpeed(10);
speed1.add(speed2);

20.0 MA

http://kahoot.com

SuperSonicSpeed speed1 = new SuperSonicSpeed(10);
SuperSonicSpeed speed2 = new SuperSonicSpeed(10);
speed1.subtract(speed2);

10.0 MA

Ponieważ metoda convert jest prywatna, nie może być on nadpisana w klasie dziedziczącej. Co prawda można zdefinować taką metodę ponownie w klasie dziedziczącej, ale ta nowa definicja nie przesłoni definicji z klasy nadrzędnej (w kontekście metod zdefiniowanych w klasie nadrzędnej).

Modyfikator protected

class Speed {
    private static final double MS_TO_KMH_RATIO = 3.6;
    
    private double value;
    private SpeedUnit unit;
    
    public Speed(double value, SpeedUnit unit){
        this.value = value;
        this.unit = unit;
    }
    
    public Speed add(Speed that){
        return new Speed(this.value + that.convert(this.unit), this.unit);
    }
    
    public Speed subtract(Speed that){
        return new Speed(this.value - that.convert(this.unit), this.unit);
    }
    
    public String toString() {
        return "" + this.value + " " + this.unit;
    }
    
    protected double convert(SpeedUnit target){
        if(this.unit == SpeedUnit.KMH && target == SpeedUnit.MS){
            return this.value / MS_TO_KMH_RATIO;
        } else if(this.unit == SpeedUnit.MS && target == SpeedUnit.KMH){
            return this.value * MS_TO_KMH_RATIO;
        } else {
            return this.value;
        }
    }   
}

class SuperSonicSpeed extends Speed {
    public SuperSonicSpeed(double value){
        super(value, SpeedUnit.MA);
    }

    protected double convert(SpeedUnit target){
        return 0;
    }
}

Speed speed1 = new SuperSonicSpeed(10);
Speed speed2 = new SuperSonicSpeed(10);
speed1.add(speed2);

10.0 MA

10 + 0 = 10

Tylko metody prywatne zachowują się w ten sposób. Są one prywatnymi składowymi klasy. To nie obiekt "ma" metody, tylko klasa "ma" metody. Dostęp do metod jest zapośredniczony w klasie.

Modyfikator final

class Speed {
    protected final double convert(SpeedUnit target){
        if(this.unit == SpeedUnit.KMH && target == SpeedUnit.MS){
            return this.value / MS_TO_KMH_RATIO;
        } else if(this.unit == SpeedUnit.MS && target == SpeedUnit.KMH){
            return this.value * MS_TO_KMH_RATIO;
        } else {
            return this.value;
        }
    }   
}

class SuperSonicSpeed extends Speed{
    public SuperSonicSpeed(double value){
        super(value, SpeedUnit.MA);
    }

    protected double convert(SpeedUnit target){
        return 0;
    }
}

|           super(value, SpeedUnit.MA);
constructor Speed in class Speed cannot be applied to given types;
  required: no arguments
  found: double,SpeedUnit
  reason: actual and formal argument lists differ in length

|       protected double convert(SpeedUnit target){
|           return 0;
|       }
convert(SpeedUnit) in SuperSonicSpeed cannot override convert(SpeedUnit) in Speed
  overridden method is final

Modyfikator final oznacza, że metoda nie może zostać nadpisana w klasie dziedziczącej. Innymi słowy taka metoda przestaje być metodą wirtualną.

Modyfikator static (metody klasowe)

class Speed {
    private double value = 10;
    
    public String toString(){
        return this.value + "";
    }
    
    public void run(){
        main(null);
    }
    
    public static void main(String[] args){
        Speed speed1 = new Speed();
        System.out.println(speed1);
    }
}

Speed.main(null);

10.0

Speed speed = new Speed();
speed.run();

10.0

Najbardziej powszechnie wykorzystywaną metodą statyczną jest main. Metoda statyczna przynależy do klasy - analogicznie jak atrybut statyczny. Dlatego może być wywołana na rzecz klasy - ale może być również wywołana w dowolnej metodzie instancyjnej.

class Speed {
    private final double value;
    
    private static Map<Double, Speed> instances = new HashMap<>();

    private Speed(double value){
        this.value = value;
    }

    public static Speed create(double value){
        if(instances.containsKey(value)){
            return instances.get(value);
        } else {
            Speed instance = new Speed(value);
            instances.put(value, instance);
            return instance;
        }
    }
}

Speed speed1 = Speed.create(10);
Speed speed2 = Speed.create(10);

speed1 == speed2

true

W metodzie statycznej mamy dostęp tylko do statycznych atrybutów klasy!

Ten przykład jest dość problematyczny, ponieważ metody statyczne nie mogą być nadpisane. W konsekwencji wiążemy implementację na wieki wieków z klasą Speed - tzn. jeśli chcielibyśmy zmienić implementację, to musimy zmienić kod, w miejscu, w którym jest odwołanie do tej metody.

Dziedziczenie a metody statyczne

class Speed {
    private double value;

    private static Map<Double, Speed> instances = new HashMap<>();

    protected Speed(double value){
        this.value = value;
    }
    
    public String toString(){
        return "" + this.value;
    }

    public static Speed create(double value){
        if(instances.containsKey(value)){
            return instances.get(value);
        } else {
            Speed instance = createInstance(value);
            instances.put(value, instance);
            return instance;
        }
    }
    
    protected static Speed createInstance(double value){
        return new Speed(value);
    }
}

class SuperSonicSpeed extends Speed {
    private SuperSonicSpeed(double value){
        super(value);
    }
    
    protected static SuperSonicSpeed createInstance(double value){
        return new SuperSonicSpeed(value * 10);
    }
}

Speed speed = SuperSonicSpeed.create(10);
speed

10.0

Wzorzec Factory

class Speed {
    private double value;
    
    // modyfikator domyślny dla konstruktora
    Speed(double value){
        this.value = value;
    }
}

class SpeedFactory {
    private Map<Double, Speed> instances = new HashMap<>();
    
    public Speed create(double value){
        if(instances.containsKey(value)){
            return instances.get(value);
        } else {
            Speed instance = new Speed(value);
            instances.put(value, instance);
            return instance;
        }
    }
}

SpeedFactory factory = new SpeedFactory();
Speed speed1 = factory.create(10);
Speed speed2 = factory.create(10);
speed1 == speed2;

true

Dlaczego? Ponieważ możemy podmienić implementację SpeedFactory!

Antywzorzec

class Speed {
    public static Speed toMs(Speed speed1){
        return new Speed(speed1.convert(SpeedUnit.MS), SpeedUnit.MS);
    }
}

Speed speed1 = new Speed(10, SpeedUnit.MS);
Speed.toMs(speed1);

// vs.

speed1.toMs();

W językach obiektowych jeśli mamy metodę statyczną akceptująca pojedynczy argument tej samej klasy, to jest to błąd. Metoda ta powinna być metodą instancyjną a nie statyczną (klasową).

Modyfikator abstract

abstract class AbstractSpaceShip {
    private Speed speed;
    
    public AbstractSpaceShip(){
        this.speed = new Speed(0, SpeedUnit.MS);
    }
    
    public abstract void start();
    
    public abstract void land();
}

Klasa abstrakcyjna może posiadać metody abstrakcyjne, tzn. metody które nie posiadaja implementacji. Klasa taka nie może mieć instancji, więc ma sens tylko w kontekście dziedziczenia. Jej utworzenie ma sens pod warunkiem, że możemy w ten sposób uniknąć duplikacji kodu, w klasach, które z niej dziedziczą.

class Rocket extends AbstractSpaceShip {
    private Engine engine;
    private Parachute parachute;

    public void start(){
        engine.start();
    }
    
    public void land(){
        parachute.open();
    }
}

class SpaceShuttle extends AbstractSpaceShip {
    private List<Booster> boosters;
    
    public void start(){
        for(Booster booster : boosters){
            booster.start();
        }
    }
    
    public void land(){
        descend(new Distance(10, DistanceUnit.KM));
    }
    
    private void descend(Distance distance){
        //...
    }
}

// aliens are coming... 

List<AbstractSpaceShip> spaceFleet = new LinkedList<>();
spaceFleet.add(new Rocket());
spaceFleet.add(new SpaceShuttle());

for(AbstractSpaceShip ship : spaceFleet){
    ship.start();
}

// rescue the World, then...

for(AbstractSpaceShip ship : spaceFleet){
    ship.land();
}

Interfejs (aka międzygębie)

interface ISpaceShip {
    void start();
    void land();
}

W interfejsie zasadniczo wszystkie metody są abstrakcyjne i publiczne. Jest on podobny do klasy abstrakcyjnej, ale interfejsy się implementuje (implements), a klasy rozszerza (extends). Co więcej interfejs nie może mieć żadnych atrybutów instancyjnych (od pewnego czasu może mieć atrybuty statyczne, które mają modyfikator final).

class Rocket implements ISpaceShip {
    public void start(){
        //...
    }
    
    public void land(){
        //...
    }
}

class SpaceShuttle implements ISpaceShip {
    public void start(){
        //...
    }

    public void land(){
        //...
    }
}

// aliens are coming... 

List<ISpaceShip> spaceFleet = new LinkedList<>();
spaceFleet.add(new Rocket());
spaceFleet.add(new SpaceShuttle());

for(AbstractSpaceShip ship : spaceFleet){
    ship.start();
}

// rescue the World, then...

for(AbstractSpaceShip ship : spaceFleet){
    ship.land();
}

|   for(AbstractSpaceShip ship : spaceFleet){
incompatible types: ISpaceShip cannot be converted to AbstractSpaceShip

Jedyne co łączy obie klasy to implementacja tego samego interfejsu. Dzięki temu można je traktować tak jakby należały do jednego typu. Implementowanie nowego interfejsu jest dużo łatwiejsze do zrobienia niż zmiana klasy, z której się dziedziczy. Dlatego zasadniczo interfejs ma powszechniejsze zastosowanie.

interface ISpaceShip {
    void start();
    void land();
    // nowa metoda
    void launchMissile();
}

Z szeroko wykorzystywanymi interfejsami wiąże się problem polegający na tym, że dodanie nowej metody - w szczególności w interfejsie, który jest zdefiniowany w JVM - oznacza konieczność doimplementowania tej metody w dziesiątka, tysiącach, a może i setkach tysięcy klas...

Modyfikator default

interface ISpaceShip {
    void start();
    void land();
    
    // nowość w Javie 8.0
    default void launchMissile(){
        InterplanetarySystem.out.
            println("Włamujemy się emacsem przez sendmeila");
        InterplanetarySystem.out.
            println("omijając potrójną ścianę ogniową");
    }
}

https://www.youtube.com/watch?v=2yk5Gsqr7bM

Dziedziczenie vs. kompozycja

abstract class Car {
    public void openDoor(DoorSpecification doorSpec){
        doors.get(doorSpec).open();
    }
    
    public abstract void drive();
}

class GasolineCar extends Car {
    private GasolineEngine engine;
    
    public void drive(){
        engine.deliverGasoline();
        engine.igniteGasoline();
        //...
    }
}

class ElectricCar extends Car {
    private List<WheelMotor> motors;
    
    public void drive(){
        for(WheelMotor motor : motors){
            motor.rotate();
        }
    }
}

Nie zawsze dziedziczenie jest najbardziej odpowiednim rozwiązaniem. W znacznie większej klasie problemów - w których chcemy uzależnić zachowanie od różnych "czynników zewnętrznych bądź wewnętrznych" - lepszym rozwiązaniem jest kompozycja, czyli "składanie całości z różnych klocków", które choć mają ten sam kształt (interfejs), to przejawiają różne zachowanie (implementacja).

class Car {
    private IDriveSystem driveSystem;
    
    public Car(IDriveSystem driveSystem){
        this.driveSystem = driveSystem;
    }
    
    public drive(){
        this.driveSystem.drive();
    }
}

interface IDriveSystem {
    void drive();
}

class ElectricDriveSystem implements IDriveSystem {
    //...
}

class GasolineDriveSystem implements IDriveSystem {
    //...
}

Car car = new Car(new GasolineDriveSystem());

http://kahoot.com